So,
the calculator shows that over 23 GiB size we turn profit positive, so that's what I was taking as the reference, and then took the rounded value for price.

Either way is fine tbh. We should pick the easiest route.

Maybe the easiest way to do so is setting the min price to 0.57 which is 23.35 GiB, which is also fine....

We can also set 0.5 and be covered againt a slightly smaller basefee max value (at the end of the day we picked the march 2025 avg because there were some oscillation back then, but it is better to come up with a fixed value, I think it won't make a huge difference)

Is it feasible to add a check that the floor price rate is available to be paid when doing createDataSet? It would solve one of the problems causing: filecoin-project/curio#726

My take away: if it's a minimum from which storage providers are paid as thing as used, this "top up" model is understandable and much better in $ units. I think it's probably better and clearer if it were a larger amount than a couple of cents. $1-5 is not unusual for top-up based usaged pricing models.

Is it feasible to add a check that the floor price rate is available to be paid when doing createDataSet?

Oh, this is a really good idea, and yes it is possible! We have a getAccountInfoIfSettled on FilecoinPay that we can use to check their balance (if they were fully settled) so we can compare that with what would be needed for initial lockup and reject early. With create+add this is nice and clean. With create, then add, it's a little more messy and we lose guarantees but you'd just get rejected at add if you used up funds in between the two calls. If nextProvingPeriod gets done immediately after create+add then Curio should have a pretty solid guarantee that there is at least 0.06 on the table if they prove for a month, with a slight window for a possible race.

See latest commit in here for that feature.

Does that also cover OperatorRateAllowanceExceeded?

Figured out how to add additional checks in there. I'm of two minds about this, mostly it's great UX, we catch errors early and can be descriptive about it - good for SPs and good for users. But it also adds complexity and gets FWSS more deeply involved in something that it feels like should be something should be able to ask Filecoin Pay to figure out for us. But it's probably fine.

• InsufficientFundsForMinimumRate - not enough deposit
• OperatorNotApproved - need to approve FWSS
• InsufficientRateAllowance - not enough approval for the minimum rate (0.06/month)
• InsufficientLockupAllowance - not enough lockup approval for minimum rate @ 30 days
• InsufficientMaxLockupPeriod - not enough lockup period approval for the 30 day lockup

But it's probably fine.

We will be able to remove it when we combine createDataSet and initial nextProvePeriod.

I'm going to merge it as is, if we want to improve stuff just a bit, let's open a new PR.